As the value and use of information continues to increase, individuals and businesses seek additional ways to process and store information. One option available to users is information handling systems. An information handling system generally processes, compiles, stores, and/or communicates information or data for business, personal, or other purposes thereby allowing users to take advantage of the value of the information. Because technology and information handling needs and requirements vary between different users or applications, information handling systems may also vary regarding what information is handled, how the information is handled, how much information is processed, stored, or communicated, and how quickly and efficiently the information may be processed, stored, or communicated. The variations in information handling systems allow for information handling systems to be general or configured for a specific user or specific use such as financial transaction processing, airline reservations, enterprise data storage, or global communications. In addition, information handling systems may include a variety of hardware and software components that may be configured to process, store, and communicate information and may include one or more computer systems, data storage systems, and networking systems.
An information handling system is commonly provided with an operating system that is stored on a storage device of the information handling system and executed by a central processing unit (CPU) of the information handling system. Devices such as CPUs are typically productized with multiple thermal design power (TDP) options that can vary over a relatively large range within a standard socket platform. For example, current (2012) Intel® X86 Xeon® E5-2400/2600 processors are offered with TDP stock keeping unit (SKU) code options of 60 W (60 Watts), 70 W, 80 W, 95 W, 115 W, 130 W, 135 W, and 150 W. TDP is the maximum indefinitely sustainable power that the CPU may draw, thus the IHS power delivery and cooling must be sized accordingly. Since TDP is worst case sustainable power consumption for a given TDP SKU, which is guaranteed by manufacturing test and screening (“binning”), the majority of individual CPUs within a TDP SKU will consume considerably lower power than TDP (over many components the CPU power will exhibit a statistical distribution under the TDP limit). In general, the higher the TDP the higher the maximum performance of the CPU. It is expected that these TDP characteristic ranges for a given standard socket platform will widen further in the future.
A typical information handling system platform may only be able to support CPUs having up to a given maximum TDP value. The maximum allowable CPU TDP for a given information handling system platform may be further limited based on the actual populated system configuration present in the information handling system (e.g., drivers, DIMMs, IO adapters, etc.), and/or by anticipated environmental conditions under which the information handling system is to be operated (e.g., air conditioned/controlled data center, office, closet, “fresh-air” cooling deployment, etc.).
Blade and multi-node rack or tower platforms include multiple CPUs, and are typically power and cooling constrained. Thus, there is a need to determine the CPU type and its related TDP within a blade or multi-node platform system to ensure sufficient system power is available to power the CPU package. In some cases, power must be reallocated from other running CPU packages by “throttling down” power to these CPU packages to ensure sufficient power exists for first time power up of a new blade or node, upon which it may report its manufacturer-designated TDP value that corresponds to its SKU value. Today, monolithic, blade, or multi-node platforms typically support multiple power supply units (PSUs), e.g., ˜495 watts, 750 watts 1100 watts may be selected for a typical server platform, and the total CPU TDP for a given server platform should be checked before deciding if the PSU type for a given platform is valid for power on. Even after power is applied to a specific CPU package, the reported TDP from the specific CPU package is the general manufacturer-designated TDP value that corresponds to the TDP value designated for the given SKU assigned to the specific CPU package, and is not the actual characteristic or measured TDP value for that specific CPU package instance. As an example, it is possible that an individual CPU package may report itself as having a manufacturer-designated TDP of 95 watt (per the assigned CPU SKU for the device), when the specific individual device actually draws only 72 watts TDP in the worst case.
The common method used by an information handling system to determine the TDP of an installed CPU is for the information handling system to perform a POST sequence, and once the Built-In Operating System (BIOS) is executing, it may read CPU internal control and status registers (CSRs) that have been hardcoded by the manufacturer with the TDP value of the CPU SKU. This method requires a full power-on of the system before the CPU TDP can be determined, and as such, is not suitable for those systems which are power constrained. Several alternative methods have been used or proposed to allow an information handling system to determine the CPU TDP before initiating a full system power-on, but all of these approaches have limitations or drawbacks as will be described.
It is known to store the above-described SKU-based TDP values and other SKU information in a Processor Information ROM (PIROM), powered and accessible with only the auxiliary power rail (Vaux) supplied, within the package of high end CPUs. This implementation is relatively costly and complex, and is therefore implemented only with relatively high end CPUs, and not suitable for processors for the mainstream server (and client) markets.
Dedicated pins have also been added to CPUs to provide a CPU TDP “bin” that indicates processor type of a given device with a 2-bit code. These pins typically can only denote up to 4 values or ranges using the 2-bit code, such as different sub-sets of processors that have different assigned TDP values: 130 watt processor, 80 watt processor, 120 watt processor, and do not distinguish SKU. Although more pins could be used to increase the number of possible bins (for instance 5 pins for 32 bins), CPU manufacturers are reluctant to dedicate scarce (and “costly”) pin resources to do so.
It has been proposed to employ a “minimal” CPU power-on state to allow a system to read an assigned CPU TDP SKU value from a CPU over a serial interface such as Intel Corporation's platform environmental control interface (PECI) of the CPU, or other similar interfaces such as System Management Bus (SMBus). However, this solution would be relatively costly, requiring additional components and greater power than the Vaux power level that is typically available. It requires the information handling system to perform a subsequent full power-on reset after the “minimal” power-on, delaying the time for POST.
It has also been proposed to hold a processor in its minimum power state during power-on self-test (POST) by asserting a thermal control circuit code (e.g., PROCHOT) or other mechanism to limit CPU power consumption while the assigned CPU TDP SKU value is read from the CPU. After reading the TDP value, POST may be continued if the read TDP value is determined to be within an acceptable TDP range for the PSU of a blade or multi-node system, or an ALERT and power-off operation may be alternately initiated if the read TDP value is determined to exceed the maximum acceptable TDP for the PSU of the system. This proposed solution delays the time for POST, does not provide actual measured TDP of the individual CPU package, and causes a potential lengthy delay for the factory/field/customer when an ALERT is generated that indicates that the CPU cannot be supported by the system PSU.
It is known to store in-system characterized device characteristics in a non-volatile memory location on a device that is separate from the CPU package, that is to be used during a subsequent system power-on. Such characteristics include CPU serial number, model/SKU number, and other “capabilities” fields to allow identification when a CPU is swapped, or for ensuring that only matching CPUs are populated within a multi-CPU system. However, this stored information is not reliable when components are swapped in the field, and the in-system characterization step for measuring and storing the information is difficult to set up and measure accurately on complex devices such as a multi-core CPUs with multiple power rails.
It has been proposed to use multiplexing “pin straps” with general purpose input/output (GPIO) interface or other IO cell pins/balls to enable assigned CPU TDP SKU value to be provided by DDR pins only under pre-power conditions, after which they return to DDR use. However, multiplexing is problematic from the standpoint of IO cell design, ESD protection circuitry, and reverse biasing.
It is known to use a resistor value provided within an AC adapter to represent a general AC adapter model number (i.e., family of AC adapters). This resistor value is read by a connected laptop computer to verify to the computer that the AC adapter is the appropriate model of adapter device for powering the laptop computer. Specific voltage levels have also been used to convey similar AC adapter information.
CPU packages have been configured to operate in a “turbo mode” that allows dynamic power (Pdyn) to exceed the CPU TDP value by up to a programmable percentage above TDP power, for up to a programmable duration (example: up to 20% above TDP for up to 10 seconds). The Pdyn value is determined during Turbo mode excursion tests, and represent the value needed for guaranteeing that AC/DC DC/DC converters and power supply units (PSUs) do not exceed their rated power.
It is known to vary the resistance or other electrical value of a given circuit under test by laser trimming resistors within the given circuit during testing to achieve a particular value.